2장. 프로그래밍, 승자는 없고 생존자만 남다

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 2장 (pp. 79~86). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

도구와 지식은 70년 내내 발전해왔는데 왜 소프트웨어 개발은 오히려 더 어려워졌는가 — 그리고 그 답이 왜 지금 바이브 코딩인가를, 1990년대 컴퓨터 그래픽스가 걸었던 길을 거울삼아 보여준다.

학습 목표

이 장을 끝내면 다음을 할 수 있다. - 지난 70년간 프로그래밍 도구·언어·지식 접근성이 발전해온 흐름을 설명한다. - 도구가 발전했는데도 소프트웨어 개발이 더 어려워진 역설의 원인을 구분한다. - 바이브 코딩에서 개발자의 역할이 "작성자"에서 "검증자·감독"으로 바뀌는 이유를 설명한다. - "시속 10마일과 100마일" 비유를 근거로 판단력이 왜 새로운 핵심 역량인지 논증한다. - 1990년대 컴퓨터 그래픽스의 사례와 지금의 AI 프로그래밍 변화를 비교한다.

전체 흐름도

70년의 언어·도구·지식 접근성 발전
              │
              ▼
        생산성 역설 ── 도구는 늘었지만 복잡성은 더 깊어졌다
        │                                    │
        ▼                                    ▼
자바스크립트 생태계의 풍자              데브옵스+IaC 까지 책임 확장
(패키지매니저~배포파이프라인)           (도커·쿠버네티스·테라폼)
        │                                    │
        └──────────────────┬─────────────────┘
                            ▼
              바이브 코딩 — 손코딩 대신 AI와 대화
                            │
        ┌───────────────────┼───────────────────┐
        ▼                                       ▼
  작가 → 감독으로 역할 전환               시속 10마일 → 100마일
  (비전 제시·검증이 핵심 역할)            (판단력이 유일한 안전벨트)
        │                                       │
        └───────────────────┬───────────────────┘
                             ▼
        1990년대 그래픽스의 사다리 (putPixel → 하드웨어 렌더링 → 유니티)
                             │
                             ▼
         결론 — 사다리를 오르며 역할은 바뀌지만 사라지지 않는다

0. 용어 사전

참고 — 위쪽 항목은 이 장을 읽기 전에 알아야 하는 선행 용어다. 낯설면 1장을 먼저 보라.

1. 70년 진보의 역설 — 왜 쉬워진 게 더 어려워졌나

프로그래밍 언어는 사람이 자연어를 쓰는 방식에 가까워지는 쪽으로 진화해왔다. 컴퓨터 구조를 몰라도 문제 자체에 집중할 수 있게 된 것이다. 개발 환경도 펀치 카드와 타자기 시대를 지나, 실시간으로 오류를 잡아주는 통합 개발 환경(IDE)까지 발전했다. 여기에 구글, 스택 오버플로, 깃허브 같은 플랫폼이 지식 접근성을 폭발적으로 끌어올려, 예전엔 몇 달 걸려야 익힐 수 있던 지식을 이제는 며칠 만에 배우는 게 가능해졌다. 언어·도구·지식이라는 세 축에서 동시에 혁신이 일어난 셈이니, 소프트웨어를 만드는 일은 과거보다 훨씬 쉬워져야 마땅해 보인다.

그런데 현실은 정반대다. 시스템의 규모와 복잡성은 나날이 커지고 있고, 디버깅과 테스트는 여전히 고통스럽다. 단순해 보이는 일조차 끝없이 늘어나는 도구와 기술이 어떻게 조합되는지 완벽히 이해해야만 풀리는 상황이 됐다. 무언가를 하려면 모든 것을 알아야 하는 지경에 이르렀는데, 문제는 그 "모든 것"이 매일 바뀐다는 데 있다. 지식을 쌓는 속도보다 지식이 낡아가는 속도가 더 빠르게 느껴지는 이유가 여기에 있다.

이 장은 이 역설을 "추상화 사다리"로 설명한다. 언어와 도구의 발전은 개발자를 사다리 꼭대기까지 밀어 올려주지만, 그 세부 사항(도구 설정, 배포 파이프라인, 장애 대응)은 사라지지 않고 다른 층위로 옮겨갈 뿐이다. 그래서 개발자는 고수준에서 일하다가도 문제가 생기면 다시 사다리를 내려가 씨름해야 하는 처지에 놓인다. 지난 수십 년간 소프트웨어 개발이 혁명적으로 발전해왔지만, 지금의 복잡성이 어느 때보다 깊다는 것은 그래서 아이러니다. 많은 개발자가 "이제는 그만한 가치가 없다"며 지쳐 코딩을 그만두는 이유도 여기에 있다.

2. 자바스크립트가 보여주는 복잡성의 민낯

이 역설을 가장 선명하게 보여주는 사례가 웹 개발, 그중에서도 자바스크립트 생태계다. 웹 애플리케이션 하나를 만들려면 다음과 같은 기술 목록을 숙지해야 한다.

• 패키지 매니저(npm, yarn)
• 번들러(webpack, rollup)
• 트랜스파일러(Babel)
• 태스크 러너(gulp, grunt)
• 테스트 프레임워크
• CSS 전처리기
• 빌드 툴체인
• 배포 파이프라인

저자는 이 목록조차 책이 출판될 시점엔 이미 구식으로 전락해 있을지 모른다고 덧붙인다. 최신 자바스크립트 문법은 언급하지도 않은 상태에서, 한 기술이 자리 잡았다 싶으면 곧바로 경쟁 기술이 등장한다. 매일 웹 개발 생태계를 모니터링하지 않는 이상 어떤 조합이 효율적인지 파악하는 일 자체가 거의 불가능해졌다. 이런 풍자적 정서를 대표하는 사례로, 호세 아기나가의 "2016년에 자바스크립트를 배우는 기분(How it feels to learn JavaScript in 2016)"이 널리 회자된다(부록 B).

여기서 끝이 아니다. "직접 만든 프로그램은 운영도 스스로 해야 한다(you build it, you run it)"는 데브옵스 철학이 자리 잡으면서, 이제는 도커와 쿠버네티스, AWS, 테라폼 같은 IaC(인프라스트럭처 as 코드) 도구까지 배워야 한다. 회사가 멀티클라우드 환경이라면 AWS와 GCP, 애저를 동시에 다뤄야 할 수도 있다. 그 결과 지금 개발자는 웹페이지의 div를 가운데 정렬하는 사소한 문제와, CI 파이프라인이 테라폼 스크립트 변경 때문에 깨지는 인프라 문제를 동시에 고민해야 하는 상황에 놓였다. 지난 수십 년의 "진보" 끝에 도달한 곳이 바로 여기다 — 도구와 지식은 늘었는데, 그만큼 다뤄야 할 대상도 함께 늘어난 것이다.

3. 이제는 더 나은 방법이 있다 — AI와 대화하는 프로그래밍

펀치 카드에서 IDE로, 책에서 스택 오버플로로 옮겨왔던 흐름의 다음 단계가 바로 바이브 코딩이다. 손으로 코드를 작성하는 대신 AI와 대화하며 만들고 싶은 것을 구현하는 시대로 들어선 것이다. 패키지 매니저나 번들러, 배포 파이프라인과 씨름할 필요 없이, "친구들이랑 대화할 때 쓸 비밀 채팅 웹 앱을 만들어줘"처럼 일상 대화체로 원하는 결과만 요청하면 된다.

모든 게 잘 돌아간다는 가정하에 AI 어시스턴트가 원하는 방식으로 소프트웨어를 만들어준다. 그러면 개발자의 역할은 무엇이 남는가 — AI가 적절한 라이브러리를 선택했는지, 테스트 스위트를 생성했는지, 모범 사례를 따르고 성능·보안 측면에서 안정적인 코드를 만들었는지를 확인하는 일이다. 이 장은 이를 영화 제작에 비유한다. 대본을 직접 쓰는 작가에서, 비전을 제시하고 방향을 잡는 감독으로 바뀌는 것이다. 제작 세부 사항은 AI 어시스턴트에게 맡기면 된다.

저자 일동은 FAAFO가 주는 혜택 때문에 바이브 코딩이 기존 방식보다 훨씬 낫다고 믿는다. 그렇다고 "바이브 코딩이 쉽다"는 뜻은 아니다. 오히려 그 어느 때보다 판단력과 경험이 중요해졌다. AI는 틀릴 수 있고, 때로는 완전히 엉뚱한 방향으로 갈 수 있다. AI와 함께하는 프로그래밍은 전통적 프로그래밍과 매우 닮아 있어서 기존에 알던 지식 대부분이 여전히 중요하다. 다만 이 새로운 방식은 LLM과 코드 사이에 실제로 무슨 일이 일어나는지를 직관적으로 이해하는 새로운 감각과 본능을 추가로 요구한다.

4. 시속 10마일과 100마일 — 판단력이 새로운 무기다

이 장은 이 변화를 운전에 비유한다. 안전하게 시속 10마일로 운전하면서 익힌 감각은 시속 100마일로 달릴 때는 그대로 통하지 않는다. 수제 코딩은 느린 속도로 진행되기 때문에 문제를 발견하고, 경계 조건을 생각하고, 서서히 방향을 수정할 여유가 있었다. 하지만 AI가 몇 초 만에 모듈을 생성하는 세상에서는 완전히 다른 사고방식과 기술이 필요하다. 이 기술을 습득하지 못하면 폭주하다가 충돌할 가능성이 높다.

그래도 희소식은 있다. 우주 비행사 프랭크 보먼은 "훌륭한 조종사는 탁월한 기술을 발휘해야 하는 상황 자체를 피하기 위해 탁월한 판단력을 사용한다"라고 말했다. AI 시대의 개발에서도 마찬가지다. 숙련된 판단력은 가장 값진 능력이자 무기가 된다. 뛰어난 기술이 이미 벌어진 위기를 수습하는 데 쓰인다면, 판단력은 애초에 그런 위기 자체가 벌어지지 않도록 막아준다 — 재난 복구 스킬을 발휘해야 하는 상황 자체를 피하게 해주는 힘인 것이다.

5. 1990년대 컴퓨터 그래픽스: 스티브의 이야기

이 변화가 낯선 것이 아니라는 것을 저자 스티브의 개인 경험이 보여준다. 1990년대 초, 스티브는 워싱턴 대학교에서 그래픽스 분야의 전설적 강사 토니 드로즈(현 픽사 연구 그룹 리더) 교수의 수업을 들었다. 강의 첫날 교수는 학생들에게 "이 수업에서 여러분이 호출할 수 있는 API는 putPixel(r, g, b, a) 단 하나입니다"라고 선언했다. 학생들은 그 한 줄의 함수만으로 3D 세계에 픽셀을 하나하나 쌓아 올려야 했다.

1992년 당시 최첨단 그래픽스 기술은 이 정도 수준이었다. 연구실 컴퓨터로 찻주전자나 체스 말 같은 정적인 장면 하나를 만드는 데도 몇 시간을 기다려야 했다. 여덟 시간을 투자한 결과물이 엉망진창인 경우가 다반사였고, 학생들은 절망에 빠져 연구실을 뛰쳐나가곤 했다.

그런데 그로부터 3년 후인 1995년, 수업은 완전히 달라졌다. 더 이상 putPixel 호출은 없었다. 하드웨어가 렌더링 대부분을 처리하는 혁신이 일어났기 때문이다. 학생들은 이제 조명, 신(scene), 애니메이션 같은 고수준 추상화 작업을 배우기 시작했다. 같은 학교의 같은 수업이 짧은 시간 안에 완전히 다른 사고방식·도구·용어를 다루는 새로운 학문으로 탈바꿈한 것이다.

생산성은 폭발적으로 향상됐다. 더 이상 찻주전자를 렌더링할 필요가 없었고, 연구실 컴퓨터로 한 편의 영화를 만드는 수준까지 올라왔다. 물론 여전히 새벽에 실패작을 보고 절망하는 학생은 있었지만, 그 이유는 물리 엔진이나 히트박스 버그 때문이었지 도형 렌더링 때문은 아니었다. 실패는 사라지지 않았지만, 실패가 일어나는 층위가 바뀐 것이다. 취업 시장도 함께 변했다 — 그래픽스 관련 직종이 계속 늘어났다. 지난 30년간 그래픽스 분야는 추상화 사다리를 끝없이 오르며 수많은 전문 분야를 배출해냈다.

그래픽스 혁명은 지금도 진행 중이다. 오늘날 고등학생도 그래픽스 코드를 한 줄도 보지 않고, 일주일짜리 게임 개발 코스만 듣고 유니티 같은 게임 엔진으로 게임을 만든다. 학생들은 어떤 수식으로 다각형을 표현할지나 픽셀 연산을 배우는 대신, 객체 모델링·맵 디자인 같은 창작에 집중한다. 렌더링 복잡성은 유니티의 물리 엔진이 알아서 처리해주기 때문이다.

6. 결론 — 그래픽스의 사다리를 소프트웨어 전체가 오른다

박사 수준의 수학 지식이 필요했던, 마법 같았던 1990년대의 컴퓨터 그래픽스는 이제 유니티나 언리얼 엔진을 다룰 줄 아는 열정적인 10대라면 누구나 익힐 수 있는 기술이 됐다. 이 장은 AI가 지금 프로그래밍 전반에 걸쳐 똑같은 마법을 펼치고 있다고 본다. 다른 점은 속도뿐이다 — 그래픽스의 변화는 수십 년에 걸쳐 일어났지만, AI가 일으키는 변화는 그보다 훨씬 빠르게 진행되고 있다. 기술이 발전하면 일의 형태와 사람의 역할은 변하고 진화한다. AI에서도 같은 변화를 보게 될 것이라는 게 이 장의 결론이다.

정점 법선 계산 대신 세계를 창조하는 일에 집중할 수 있어야 그래픽스 개발이 재밌어진다. 마찬가지로 세미콜론을 빠뜨려서 생기는 버그를 찾는 것보다 흥미로운 무언가를 만드는 데 집중할 때 프로그래밍이 즐거워진다. 물론 누군가는 기술적 난제가 사라져가는 것을 애도하기도 한다 — 지금도 가끔 어셈블리 언어로 텍스처 매핑을 하던 시절을 추억하는 그래픽스 엔지니어를 만날 수 있다. 하지만 대부분의 사람은 무엇이 가능한지 깨닫는 순간, 그 변화를 축복하며 기꺼이 받아들일 것이다. 그래픽스 산업에서 일어났던 변화가 지금 소프트웨어 산업 전반에서 다시 일어나고 있다. 바이브 코딩은 불필요한 세부 사항에서 우리를 해방시키고, 진짜 멋진 작품을 만들 수 있게 도와줄 것이다. FAAFO 세상이 열렸다.

핵심 개념 정리

실무 체크리스트

• [ ] AI가 새로 추가한 라이브러리·의존성을 실제로 검토했는가?
• [ ] AI가 생성한 코드에 테스트 스위트가 실제로 갖춰졌는지 확인했는가?
• [ ] 시속 100마일 비유처럼, AI가 몇 초 만에 만든 모듈을 검증할 시간을 미리 확보했는가?
• [ ] 판단력이 필요한 순간을 줄이기 위해, 작업 지시(방향) 단계에서 충분히 구체적으로 요구했는가?
• [ ] "AI가 다 해준다"는 기대로 보안·성능 검토를 건너뛰지 않았는가?
• [ ] 지금 쓰는 기술 스택이 이 문서를 쓰는 시점보다 더 빠르게 바뀔 수 있다는 것을 감안했는가?
• [ ] AI가 선택한 아키텍처·인프라가 실제 배포 환경(멀티클라우드 등)과 맞는지 확인했는가?
• [ ] IaC·컨테이너처럼 운영 범위까지 AI에게 맡길 때, 운영 책임 소재를 명확히 했는가?
• [ ] 추상화 사다리를 오른 뒤에도, 사라지지 않는 기본기(테스트·디버깅 사고)를 유지하고 있는가?

연습문제

1. 시나리오 판단. 팀에 합류한 신입 개발자가 "AI가 코드를 다 짜주는데 왜 아직 기존 프로그래밍 지식이 필요한가요?"라고 묻는다. 이 장의 논지를 바탕으로 어떻게 답할 것인가?
2. 적용. "시속 10마일로 운전하며 익힌 감각은 시속 100마일에서 통하지 않는다"는 비유를 팀의 코드 리뷰·배포 프로세스에 적용한다면, 구체적으로 무엇을 바꿔야 하는가?
3. 비교. 웹 애플리케이션 하나를 만드는 데 필요했던 기술 목록(패키지 매니저부터 배포 파이프라인까지)과, 오늘날 AI 어시스턴트에게 같은 일을 맡길 때 개발자에게 남는 역할의 차이를 설명하라.
4. 성찰. 1990년대 그래픽스 프로그래머가 겪은 사다리 이동과, 지금 소프트웨어 개발자가 겪고 있는 사다리 이동에서 같은 점과 다른 점은 무엇인가?

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1/원문 인용 확인, 생존 확인 2026-09-14)

• 자바스크립트 생태계의 복잡성을 풍자한 원 사례(원문이 직접 인용한 자료) — Jose Aguinaga, "How it feels to learn JavaScript in 2016"
• "you build it, you run it"의 출처 — Werner Vogels 인터뷰 인용 (AWS 공식 블로그) — 원 인터뷰는 2006년 ACM Queue의 "A Conversation with Werner Vogels"이며, 이 AWS 공식 블로그가 해당 구절을 그대로 인용해 소개한다.

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) 이 장은 기존 프로그래밍 지식이 사라지는 게 아니라 그 쓰임이 바뀐다고 말한다. AI와 함께하는 프로그래밍은 전통적 프로그래밍과 닮아 있어 기존 지식 대부분이 여전히 중요하며, 다만 LLM과 코드 사이에 실제로 무슨 일이 일어나는지 직관적으로 이해하는 새로운 감각이 추가로 필요하다. 즉 "지식이 필요 없다"가 아니라 "지식 위에 판단력이라는 층이 하나 더 쌓인다"가 정확한 답이다.
2. (문제 2 정답) 손코딩은 느린 속도 덕분에 문제 발견·경계 조건 검토·점진적 수정의 여유가 있었지만, AI가 모듈을 몇 초 만에 생성하는 환경에서는 그 여유가 사라진다. 따라서 코드 리뷰는 "다 만든 뒤 검토"에서, AI에게 방향을 명확히 지시하고 생성 직후 즉시 검증하는 체제로 바뀌어야 한다 — 라이브러리 선택, 테스트 스위트, 보안·성능을 확인하는 절차를 배포 전 단계에 촘촘히 넣는 식이다.
3. (문제 3 정답) 전통적으로는 패키지 매니저·번들러·트랜스파일러·태스크 러너·테스트 프레임워크·CSS 전처리기·빌드 툴체인·배포 파이프라인을 모두 알아야 웹 애플리케이션 하나를 만들 수 있었다. 바이브 코딩에서는 이 세부 사항을 AI 어시스턴트에게 맡기고, 개발자는 적절한 라이브러리를 선택했는지, 테스트가 갖춰졌는지, 모범 사례·성능·보안이 지켜졌는지를 확인하는 역할로 옮겨간다 — 대본을 쓰는 작가에서 비전을 제시하는 감독으로 바뀌는 것과 같다.
4. (문제 4 정답) 같은 점은 둘 다 세부 구현을 몰라도 되는 추상화 사다리를 오르며, 그 결과 진입장벽이 낮아져 더 많은 사람이 창작에 참여하게 된다는 것이다(1992년 putPixel만 쓰던 대학원 수업 → 오늘날 고등학생의 유니티 게임 개발). 다른 점은 속도다 — 그래픽스의 변화는 수십 년에 걸쳐 일어났지만, AI가 프로그래밍 전반에 일으키는 변화는 그보다 훨씬 빠르게 진행되고 있다.